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Abstract 
This document defines an RTP Control Protocol (RICP) Extended Report 
(XR) block that allows the reporting of packet delay variation 
metrics for a range of RTP applications. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 
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Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
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Introduction 
1. Packet Delay Variation Metrics Block 


This document defines a new block type to augment those defined in 
[RFC3611], for use in a range of RTP applications. 


The new block type provides information on Packet Delay Variation 
(PDV) using one of several standard metrics, for example, Mean 
Absolute Packet Delay Variation 2 (MAPDV2) (Clause 6.2.3.2 of 
[G.1020]) or 2-point PDV (Clause 6.2.4 of [Y.1540]). 


The metrics belong to the class of transport metrics defined in 
[MONARCH] . 


-2. RTCP and RTCP XR Reports 


The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 
defined an extensible structure for reporting using an RICP Extended 
Report (XR). This document defines a new Extended Report block for 
use with [RFC3550] and [RFC3611]. 


.3. Performance Metrics Framework 
The Performance Metrics Framework [RFC6390] provides guidance on the 
definition and specification of performance metrics. The RIP 
monitoring architectures [MONARCH] provides guidelines for reporting 
block format using RTCP XR. The XR block described in this document 
is in accordance with the guidelines in [RFC6390] and [MONARCH]. 

4. Applicability 


These metrics are applicable to a wide range of RIP applications in 
which the application streams are sensitive to delay variation 
[RFC5481]. For example, applications could use the measurements of 
these metrics to help adjust the size of adaptive jitter buffers to 
improve performance. Network managers can use these metrics to 
compare actual delay variation to targets (i.e., a numerical 
objective or Service Level Agreement) to help ensure the quality of 
real-time application performance. 


Terminology 
.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2.2. Notations 


This report block makes use of binary fractions. The terminology 
used is 


Numeric formats S X:Y 


where S indicates a two’s complement signed representation, X 
the number of bits prior to the decimal place, and Y the number 
of bits after the decimal place. 


Hence, 8:8 represents an unsigned number in the range 0.0 to 
255.996 with a granularity of 0.0039. S7:8 represents the 
range -127.996 to +127.996. 0:16 represents a proper binary 
fraction with range as follows: 


0.0 to 1 - 1/65536 = 0.9999847 


however, note that use of flag values at the top of the numeric 
range slightly reduces this upper limit. For example, if the 
16-bit values Oxfffe and Oxffff are used as flags for "over- 
range" and "unavailable" conditions, a 0:16 quantity has a 
range as follows: 


0.0 to 1 - 3/65536 = 0.9999542 
3. Packet Delay Variation Metrics Block 


Metrics in this block report on packet delay variation in the stream 
arriving at the RTP system. The measurement of these metrics is made 
at the receiving end of the RTP stream. Instances of this metric 
block refer by synchronization source (SSRC) to the separate 
auxiliary Measurement Information Block [RFC6776], which contains 
measurement intervals. This metric block relies on the measurement 
interval given by the value of the "Measurement Duration (Interval)" 
field in the Measurement Information Block to indicate the span of 
the report and MUST be sent in the same compound RTCP packet as the 
Measurement Information Block. If the measurement interval is not 
received for this metric block, this metric block MUST be discarded. 
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3.1. Report Block Structure 
PDV metrics block: 


0 1 2 3 
O-12°3.4 5.67 8 9 0-1 2:3 4-59 6 7.89 O71 23 4°56 789.01 


dd O RO A A A A + 4-4-4 -F-t ttt o O O O A Rh o o o o + + + 
| BT=15 | L |pdvtyp |Rsv | block length=4 

dd O RO A O A A O 4-4-4 -4-t tt ttt 4-4 Fatt tito o o o o ++ 
| SSRC of Source | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| Pos PDV Threshold/Peak | Pos PDV Percentile 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| Neg PDV Threshold/Peak | Neg PDV Percentile 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| Mean PDV | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


Figure 1: Report Block Structure 
3.2. Definition of Fields in PDV Metrics Block 
Block type (BT): 8 bits 


A Packet Delay Variation Metrics Block is identified by the 
constant 15. 


Interval Metric flag (I): 2 bit 


This field is used to indicate whether the Packet Delay Variation 
metrics are Sampled, Interval, or Cumulative metrics [MONARCH], 
that is, whether the reported values apply to the most recent 
measurement interval duration between successive metrics reports 
(I=10) (the Interval Duration), or they apply to the accumulation 
period characteristic of cumulative measurements (I=11) (the 
Cumulative Duration), or they are a sampled instantaneous value 
(I=01) (Sampled Value). The value I=00 is reserved and MUST NOT 
be used. If the value I=00 is received, then the XR block MUST be 
ignored by the receiver. 


Packet Delay Variation Metric Type (pdvtyp): 4 bits 
Packet Delay Variation Metric Type is of type enumerated and is 
interpreted as an unsigned, 4-bit integer. This field is used to 


identify the Packet Delay Variation Metric Type used in this 
report block, according to the following code: 
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bits 014-011 
0: MAPDV2, Clause 6.2.3.2 of [G.1020], 
1: 2-point PDV, Clause 6.2.4 of [Y.1540]. 
Rsv: 2 bits 
This field is reserved for future definition. In the absence of 
such a definition, the bits in this field MUST be set to zero and 
ignored by the receiver. 
block length: 16 bits 
The length of this report block is in 32-bit words, minus one. 
For the Packet Delay Variation Metrics Block, the block length is 
equal to 4. 
SSRC of source: 32 bits 
This field is as defined in Section 4.1 of [RFC3611]. 
Positive PDV Threshold/Peak: 16 bits 
This field is associated with the Positive PDV percentile and 
expressed in milliseconds with numeric format S11:4. The term 


"Positive" represents that the packets are arriving later than the 
expected time. 


If the measured value is less than -2047.9375 (the value that 
would be coded as 0x8001), the value 0x8000 SHOULD be reported to 
indicate an over-range negative measurement. If the measured 
value is greater than +2047.8125 (the value that would be coded as 
Ox7FFD), the value Ox7FFE SHOULD be reported to indicate an over- 
range positive measurement. If the measurement is unavailable, 
the value Ox7FFF MUST be reported. 


Positive PDV Percentile: 16 bits 


This field indicates the percentages of packets in the RTP stream 
for which individual packet delays were less than the Positive PDV 
Threshold. It is expressed in numeric format 8:8 with values from 
O to 100th percentile. 


If the measurement is unavailable, the value OxFFFF MUST be 
reported. 
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Negative PDV Threshold/Peak: 16 bits 


This field is associated with the Negative PDV percentile and 
expressed in milliseconds with numeric format S11:4. The term 
"Negative" represents that the packets are arriving earlier than 
the expected time. 


If the measured value is more negative than -2047.9375 (the value 
that would be coded as 0x8001), the value 0x8000 SHOULD be 
reported to indicate an over-range negative measurement. If the 
measured value is more positive than +2047.8125 (the value that 
would be coded as Ox7FFD), the value Ox7FFE SHOULD be reported to 
indicate an over-range positive measurement. If the measurement 
is unavailable, the value Ox7FFF MUST be reported. 


Negative PDV Percentile: 16 bits 


This field indicates the percentages of packets in the RTP stream 
for which individual packet delays were more than the Negative PDV 
Threshold. It is expressed in numeric format 8:8 with values from 
O to 100th percentile. 


If the measurement is unavailable, the value OxFFFF MUST be 
reported. 


If the PDV Type indicated is 2-point PDV and the Positive and 
Negative PDV percentiles are set to 100.0, then the Positive and 
Negative Threshold/Peak PDV values are the peak values measured 
during the reporting interval (which may be from the start of the 
call for cumulative reports). In this case, the difference 
between the Positive and Negative Threshold/Peak values defines 
the range of 2-point PDV. 


Mean PDV: 16 bits 


The mean PDV value of data packets is expressed in milliseconds 
with Numeric format S11:4 format. 


For MAPDV2, this value is generated according to Clause 6.2.3.2 of 
[G.1020]. For interval reports, the MAPDV2 value is reset at the 
start of the interval. 


For 2-point PDV, the value reported is the mean of per-packet 
2-point PDV values. This metric indicates the arrival time of the 
first media packet of the session with respect to the mean of the 
arrival times of every packet of the session. A single value of 
the metric (for a single session) may not be useful by itself, but 
its average over a number of sessions may be useful in diagnosing 
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media delay at session startup. For example, this might occur if 
media packets are often delayed behind signaling packets due to 
head-of-line blocking. 


If the measured value is more negative than -2047.9375 (the value 
that would be coded as 0x8001), the value 0x8000 SHOULD be 
reported to indicate an over-range negative measurement. If the 
measured value is more positive than +2047.8125 (the value that 
would be coded as Ox7FFD), the value 0x7FFE SHOULD be reported to 
indicate an over-range positive measurement. If the measurement 
is unavailable, the value Ox7FFF MUST be reported. 


Reserved: 16 bits 


These bits are reserved for future definition. They MUST be set 
to zero by the sender and ignored by the receiver. 


3.3. Guidance on Use of PDV Metrics 


This subsection provides informative guidance on when it might be 
appropriate to use each of the PDV metric types. 


MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous 
(per-packet) delay when compared to the short-term moving average 
delay. This metric could be useful in determining residual 
impairment when an RTP end system uses an adaptive de-jitter buffer 
that tracks the average delay variation, provided that the averaging 
behavior of the adaptive algorithm is similar to that of the MAPDV2 
algorithm. 


2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay 
variation with respect to a defined reference packet transfer delay. 
Note that the reference packet is generally selected as the packet 
with minimum delay based on the most common criterion (see Sections 1 
and 5.1 of [RFC5481]). In an RTP context, the two "points" are at 
the sender (the synchronization source that applies RTP timestamps) 
and at the receiver. The value of this metric for the packet with 
index j is identical to the quantity D(i,j) defined in Section 6.4.1 
of [RFC3550], and the packet index i should be set equal to the index 
of the reference packet for the metric in practice. The metric 
includes the effect of the frequency offsets of clocks in both the 
sender and receiver end systems, so it is useful mainly in networks 
where synchronization is distributed. As well as measuring packet 
delay variation in such networks, it may be used to ensure that 
synchronization is effective, for example, where the network carries 
ISDN data traffic over RTP [RFC4040]. The metric is likely to be 
useful in networks that use fixed de-jitter buffering, because it may 
be used to determine the length of the required de-jitter buffer, or 
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to determine if network performance has deteriorated such that 
existing de-jitter buffers are too small to accommodate the observed 
delay variation. 


3.4. Examples of Use 
(a) To report MAPDV2 [G.1020]: 


Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV 
Threshold = 50.0 (note this implies -50 ms); Neg PDV Percentile 
= 98.4; PDV type = 0 (MAPDV2) 


causes average MAPDV2 to be reported in the Mean PDV field. 


Note that implementations either may fix the reported 
percentile and calculate the associated PDV level or may fix a 
threshold PDV level and calculate the associated percentile. 
From a practical implementation perspective, it is simpler to 
use the second of these approaches (except of course in the 
extreme case of the 100th percentile). 


(b) To report 2-point PDV [Y.1540]: 


Pos PDV Threshold = 60 (note this implies +60 ms); Pos PDV 
Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile = 
0; PDV type = 1 (2-point PDV) 


causes 2-point PDV to be reported in the Mean PDV field. 


2-point PDV, according to [Y.1540] is the difference in delay 
between the current packet and the referenced packet of the 
stream. If the sending and receiving clocks are not 
synchronized, this metric includes the effect of relative 
timing drift. 


4. SDP Signaling 


[RFC3611] defines the use of the Session Description Protocol (SDP) 
[RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 
without prior signaling. 


This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 


in [RFC3611] by providing an additional value of "xr-format" to 
signal the use of the report block defined in this document. 
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xr-format =/ xr-pdv-block 


xr-pdv-block = "pkt-dly-var" [ "," pdvtype 1 [ "," nspec "," pspec ] 
pdvtype = "pdv=" CTO ; MAPDV2 ITU-T G.1020 
fe Men ; 2-point PDV ITU-T Y.1540 
/ 1*2DIGIT ) ;Value 2715 are valid and 
¡reserved for future use 
nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms) 
/ ("npc=" fixpoint ) j; negative PDV percentile 
pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms) 
/ ("ppc=" fixpoint) ; positive PDV percentile 
fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal 
DIGIT = <as defined in Section 3.4 of [RFC5234]> 


When SDP is used in offer/answer, a system sending SDP may request a 
specific type of PDV measurement. In addition, they may state a 
specific percentile or threshold value and expect to receive the 
corresponding threshold or percentile metric, respectively. The 
system receiving the SDP SHOULD send the PDV metrics requested, but 
if the metric is not available, the system receiving the SDP MUST 
send the metric block with the flag value indicating that the metric 
is unavailable. 


IANA Considerations 
New block types for RTCP XR are subject to IANA registration. For 
general guidelines on IANA considerations for RTCP XR, refer to 
[RFC3611]. 


.1. New RTCP XR Block Type Value 


This document assigns the block type value 15 in the IANA "RTCP XR 
Block Type" registry to the "Packet Delay Variation Metrics Block". 


.2. New RTCP XR SDP Parameter 


This document also registers a new parameter "pkt-dly-var" in the 
"RTCP XR SDP Parameters" registry. 
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5.3. Contact Information for Registrations 
The contact information for the registrations is: 
Qin Wu (sunseawq@huawei.com) 
101 Software Avenue, Yuhua District 
Nanjing, Jiangsu 210012 


China 


5.4. New Registry of PDV Types 


This document creates a new registry to be called "RTCP XR PDV block 
- PDV type" as a sub-registry of the "RTP Control Protocol Extended 
Reports (RTCP XR) Block Type Registry". Policies for this new 
registry are as follows: 


o The information required to support an assignment is an 
unambiguous definition of the new metric, covering the base 
measurements and how they are processed to generate the reported 
metric. This should include the units of measurement, how values 
of the metric are reported in the three 16-bit fields "Pos PDV 
Threshold/Peak", "Neg PDV Threshold/Peak", and "Mean PDV" within 
the report block, and how the metric uses the two 16-bit fields 
"Pos PDV Percentile" and "Neg PDV Percentile". 


o The review process for the registry is "Specification Required" as 
described in Section 4.1 of [RFC5226]. 


o Entries in the registry are unsigned 4-bit integers. The valid 
range is 0 to 15 corresponding to the 4-bit field "pdvtyp" in the 
block. Values are to be recorded in decimal. 

o Initial assignments are as follows: 

x 0: MAPDV2, Clause 6.2.3.2 of [G.1020], 
* 1: 2-point PDV, Clause 6.2.4 of [Y.1540], 
* 2-15: Reserved for future use. 

6. Security Considerations 

It is believed that this proposed RTCP XR block introduces no new 

security considerations beyond those described in [RFC3611]. This 

block does not provide per-packet statistics so the risk to 


confidentiality documented in Section 7, paragraph 3, of [RFC3611] 
does not apply. 
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